1. Field
This application relates generally to techniques for reducing the engineering time and effort required to integrate heterogeneous components into a final system and/or system of systems. Embodiments relate to a software framework, with hardware options, to enable integration of a disparate set of software and hardware components into a final system and/or system of systems that does not require the components to match a standard agreed upon before integration.
2. Description of Related Art
A robot is any system, having one or more processors (where a processor can be a hardware or software entity that performs calculations), that is able to perform a task, and includes zero or more devices, where a device can be a hardware actuator/sensor/system or software application/system producing and/or receiving one or more signals, attached to said processor(s). Note that embodiments of robots can be mobile (such as unmanned vehicles) or immobile (such as automated banking machines). A robotic control system is a system to control a robot and may, in some implementations, be embodied as a purely software solution running atop generic hardware or as a solution with both software and hardware components (machines). In some cases, a purely software solution is a subset of the functionality of a machine solution.
Machines are used in almost every facet of life, and as such, many control systems have been developed to control the behavior of these machines. Robotic control systems include the categories of informal systems that are used to control any piece of hardware and those formal control systems designed for the sole purpose of coordinating a set of hardware in a given task. In some implementations, the latter is primarily of interest. Typically, a specific robotic task, which may encapsulate both physical work and digital signal processing, is organized as a standard control problem whereby the behavior of a dynamic system has a desired output called the reference. When the behavior of a system needs to follow a certain reference over time, a controller utilizes, for example, inputs to the system, historic states, and trends to manipulate the outputs and obtain the desired effect of the system.
The simple approach to integrating components into a system is to build a system where the components work together directly. This ‘stovepipe’ approach in robotic control systems (see, e.g., FIG. 1) is to define a unique set of input devices with known attributes, capabilities, and means of communication with a unique set of output devices also having known attributes, capabilities, and means of communication, and to specify a control system that depends directly on the devices used in the application. In this approach, the flow of control follows the standard control systems formula: ƒ(I)=O, where the output O of the system is the controller function ƒ applied to the input I given a goal G. In this approach, there is a complete dependence on the input and output devices' attributes, capabilities, and means of communication. This approach is still the most common method in use today due to the simplicity and ease of defining a system with these properties. By customizing a control system to the specific signal(s) received from input devices to match against a set of expected inputs, the system controller can send signal(s) to output devices to match against a set of expected outputs.
In many cases, the stovepipe approach will not satisfy higher-level control requirements of a robotic control system. Often, as more complex control constructs are required to fully describe the appropriate behavior of a system, a level of abstraction is added between each of the inputs, the controller, and the outputs. This ‘interface’ approach to robotic control systems (see, e.g., FIG. 2) builds on the stovepipe approach by abstracting away from the exact signals that are delivered by the inputs to the system controller and from the exact signals delivered by the controller to the outputs. This approach favors a generalized form of communication between each component. With a new level of abstraction, the controller can be given access to a variety of information that matches a particular interface form from both input and output devices, so that the controller need not know about the specific means of communication the devices employ. In this sort of approach, the flow of control follows a modified control systems formula: ƒ(g(I))=h(O), where the output O of the system is a transformation h of the controller function ƒ applied to the transformation g of input I given goal G. In this equation, g and h are abstraction layers that convert the exact input signal I and exact output signal O, respectively, to match the signal interface of the controller (which may be an exact signal or an interface signal of the controller). Note, however, that the interface approach still depends entirely on the inputs' and outputs' attributes, capabilities, and means of communication, in order to achieve the goals of the system, because the interface abstraction(s) require this knowledge in order to effect the translation.
Several groups have developed specifications for robotic control systems that address some of the limitations of the standard control-theory inspired approaches. The leading technologies rely on the same principles already discussed and have been created to be adaptable to existing standards in the combined domains of robotic control systems and software engineering, which is a subset of robotic control systems. These architectural frameworks facilitate component and interface standards development, including: command and control, communication, operating environments, safety, security, software architectures, user interface, data formats for transmission, and more.
Systems designed using the interface abstraction methodology explicitly define the g(x) and h(x) interfaces mentioned above, as well as a complete architecture for the controller ƒ(x) and often the internal interfaces of the controller, because complex controllers are comprised of many smaller components (which can lead to integration problems). In this methodology, a robotic control system designer is free to implement the specified control architecture in whatever manner is most appropriate when following the specifications of current systems, since specifications for the control architecture seldom define more than a set of modules and how they work together to solve a problem. Likewise, the current approach of agreeing a priori to specification details of how the device abstraction communication should be presented to the control architecture leaves the designer to determine the details of transforming the data presented by the input and output devices. Current robotic control system specifications may or may not specify exact devices required for a control system. Nevertheless, these specifications require that the type of input and output devices available to the system be determined before the design of the system. One reason for this is that data is passed from one component to another according to control systems theory in a well specified manner. The data format is defined by the interface abstractions which depend on the type of device(s) using the interface abstraction in order to determine what data can be exchanged via the interface, rather than for the type of information produced/required by the device.
Several robotic control system specifications have been developed and trialed in the lab and in real world applications with varying degrees of success. A specific type of robotic control system, known as a real-time high-availability system, has gained the greatest adoption rate across all industries. In order to build a real-time high-availability system which is highly-efficient and customized for a given application, state of the art specifications require all available resources be known a priori before the system is designed. Several existing systems attempt to define cross-platform device standards. But the typical result is a system that is only capable of being used with another exactly-mapped set of devices instead of a truly unique and flexible set of devices. Standards cannot anticipate all future device capabilities and thus a standard's template will eventually fail to encompass the needed functionality unless it is updated, which often breaks backwards-binary compatibility.
Relating to hardware, it is not easy to connect general purpose peripheral devices (such as, e.g., a display device like a monitor, etc., an input device like a keyboard, etc., and a telecommunications device like a network, etc). to the data bus and to the robot control apparatus, since architecture of the hardware such as the data bus is a customized component. It is therefore typically necessary to prepare a separate custom-made interface individually for connecting the robot control apparatus to each of these devices, in order to use them. Since there is a great deal of restriction to the kind of peripheral devices that can be connected and used with the robot control apparatus, this presents yet another problem that makes it difficult to expand the system easily.
Relating to software, the tasks performed by robots are defined programmatically using a software development system. The software implementation, however, is subject to similar constraints of hardware in that the software system as a whole is customized as well. Similar to a hardware device's connection, a software module's interface should be compatible in order to use it with other software module interfaces. The manner by which software modules are combined is highly variable and often custom to each particular system architecture.
In general, current robotic control systems require a well-defined structure for control architecture and data specifications that system designers should ensure components adhere to, in order to maintain interoperability. If a component does not meet the specification exactly, either selection of an exactly-mapped component (as mentioned above) or the re-development/re-engineering of the interface abstraction(s) is usually required. One possible problem with the abstraction methodology is that systems have many components that rely on the same template(s) for information exchange—otherwise there would be little interoperability advantage to templates—that support certain capabilities but not others. This may lead to inherent dependencies on shared templates that, when the template changes to allow additional functionality to meet a new need, breaks compatibilities with many related, as well as unrelated, components.